home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1018 < prev    next >
Text File  |  1994-08-27  |  6KB  |  139 lines
  1. Subject: Gem List
  2. Subject:  Re: GEM-List
  3. Subject:  Re: digest
  4. Date: Mon, 25 Jul 94 20:57 EST
  5. From: "Daniel J. Hollis" <0006795560@mcimail.com>
  6. To: ems <gem-list@world.std.com>
  7. Subject: Gem List
  8. Message-Id: <62940726015726/0006795560PK4EM@mcimail.com>
  9. Precedence: bulk
  10.  
  11. Subject:  Re: GEM-List
  12.  
  13. Warwick:
  14. --------
  15. >Now he's arguing with the author of the library about its size, when
  16. >the archive is sitting there for all to see, at atari.archive.  The
  17. >archive is dated 23/11/93, and contains files with the sizes I quoted above.  
  18. >As for `they bombed more often than not', I can say that the example.prg
  19. >of GEM++ 1.99 only runs on 68030 machines, due to GCC 2.5.7 being used to
  20. >compile it.
  21.  
  22. Another thing I'd like to add to this is that not everyone has a 68030 in
  23. their machine...  :-(
  24.  
  25. >I'm truly getting annoyed here, and I apologize to gem-list readers for
  26. >having to re-iterate myself due to Dan/Ken's posting of vastly
  27. >incorrect and unchecked `information'.
  28.  
  29. I don't quite think you know what you're talking about at this point,
  30. Warwick.  What is "incorrect and unchecked" may be incorrect by your
  31. beliefs.  Since I've had over 7 years of GEM programming experience,
  32. I am speaking from *EXPERIENCE* and not from opinionated lingo.  If anyone
  33. should be apologizing, it's me, but I have nothing to apologize about.
  34. You seem to like to argue about all *opinions* I have posted, and like to
  35. backfire against anything we say against GEM or any other libraries as
  36. a matter of fact.
  37.  
  38. Besides, I thought this conference was for discussing standards, and not
  39. arguing over stupid little piddly crap like this.
  40.  
  41. -- Ken Hollis (Bitgate Software)
  42. -----
  43. Subject:  Re: digest
  44.  
  45. Whomever:
  46. ---------
  47. > I would like to see a demo of WinLIB Pro and whatever other libraries 
  48. > people are working on.
  49.  
  50. WinLIB PRO has changed over to XAES.  Send me a personal message (via
  51. EMail) and I can send you a copy.  Write to khollis@bitsink.gbdata.com.
  52.  
  53. > Here's an idea for operating back-ground windows...  put an event 
  54. > rectangle around your window and watch for the mouse to move outside of 
  55. > your window.
  56.  
  57. This is not necessary, and it is very time-wasting.  Considering, that
  58. when you move your mouse, you are checking the rectangles under the mouse
  59. for which object your mouse moves under for the top window.  Remember, when
  60. the mouse leaves the window, objc_find reports a -1 (for desktop) and you
  61. can then do other things like move icons on desktop or whatever.  Your
  62. method is inefficient.  Try re-designing and re-thinking it.  I'm not trying
  63. to insult you, but, just think about it.  :-)
  64.  
  65. > When it does, monitor all mouse activity [wind_update(BEG_MCTRL)], and 
  66. > when you get a click, process it.
  67.  
  68. Monitor *all* mouse activity?  Ouch!  I thought that's what everyone else
  69. was flaming us about; it's too "busy-waiting"...
  70.  
  71. > If it's an action on one of YOUR windows, then select buttons, whatever;
  72. > top if necessary.  If it's someone else's window, send a message to the 
  73. > application, telling it to top the window.
  74.  
  75. Simply do this:  A button "press" activates a dialog inside a background
  76. window.  A button "click" tops the window.  Press meaning hold down the
  77. mouse button.  Click meaning tapping the mouse button.
  78.  
  79. > 1.  When you find another app's window and find out its handle, how do 
  80. >     you get the application ID of that app so you can send it a message?
  81.  
  82. >From what I understand, there's no real easy way.  Sure, you can get the
  83. window handle, but the only way to really get the application ID of the
  84. owner is to use WF_OWNER.  Another way is to use appl_find("PROGNAME") and
  85. check if it is installed...  I think that's not possible any other way
  86. except with WF_OWNER.
  87.  
  88. > 2.  How do you detect the presence of MultiTOS?
  89.  
  90. Simple:  Get cookie "MiNT" and check TOS version.  Or, you can use the
  91. GemParBlk to find the global[1] variable which tells you if it can multitask
  92. or not.  -1 = Multitasking, 0 = Not multitasking.
  93.  
  94. > 3.  How do you detect the presence of Geneva?
  95.  
  96. Check cookie "GNVA"
  97.  
  98. > 4.  How do you make a window untoppable under MultiTOS and Geneva?
  99.  
  100. I don't think there's a window setting that you can use to do this.  I think
  101. it all depends on your library.  I could be wrong (if I am, the index is
  102. not in my GEM Master Listing) but I'm probably right.
  103.  
  104. > 5.  My compiler (Lattice C 5.6) has full support for MultiTOS... what do 
  105. >     I do about Geneva?
  106.  
  107. But it and get the header file and developmental docs.
  108.  
  109. > Could someone give me replacement code for form_button?  I'm sure I could 
  110. > do it myself (and in fact will), but I just want to make sure that I'm 
  111. > not missing something.  I need to know what it does in detail.
  112.  
  113. What type of code are you looking for?  Try using atari.archive.umich.edu
  114. and checking the programming directory, or use ftp.uni-kl.de to check its
  115. programming directory.  E-GEM is a very good example of form_button code.
  116. Once I release XAES's source, you will also see our form_button code which
  117. is highly optimized.
  118.  
  119. > Oh, and objc_edit code would be nice too.  :)  Although, I don't believe 
  120. > in sending keypresses to anything other than the top window, so 
  121. > replacement objc_edit wouldn't be very useful.  <shrug>
  122.  
  123. The only real reason you would create your own objc_edit routine is to
  124. have INSERT/REPLACE, or to have a scrollable text object (like allowing the
  125. user to enter 40+ characters in a field)
  126.  
  127. > Are the icons on the desktop part of a desktop form?  If so, how do 
  128. > programs get away with replacing the the background without removing the 
  129. > desktop's object tree?
  130.  
  131. When you set WF_SCREEN, you are placing a dialog on the desktop.  This
  132. dialog gets redrawn automatically by GEM, so when you move a window over it,
  133. it automatically redraws itself.  To FORCE a redraw of the desktop, all you
  134. have to do is send a form_dial(3, 0, deskx, desky, deskw, deskh, deskx,
  135. desky, deskw, deskh).  That is documented in MultiTOS documentation too.
  136.  
  137. -- Ken Hollis (Bitgate Software)
  138.  
  139.